With the emergence of 3G mobile telephony, new packet-based communication technologies using IP (Internet Protocol) have been developed to support wireless communication of multimedia. For example, communication protocols in GPRS (General Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) support packet-switched multimedia services, as well as traditional circuit-switched voice calls.
A network architecture called “IP Multimedia Subsystem” (IMS) has been developed by the 3rd Generation Partnership Project (3GPP) as a platform for handling multimedia services and sessions in the packet domain, based on IP transport. Thus, an IMS network can be used to initiate and control multimedia sessions for any IP enabled terminals being connected to any type of access networks. A signalling protocol called “SIP” (Session Initiation Protocol, according to the standard IETF RFC 3261) is typically used for handling sessions in IMS networks. A “SIP-enabled” terminal can thus use this standard to initiate and terminate multimedia communications with other terminals and servers by means of its home IMS network.
FIG. 1 is a simplified schematic illustration of a basic network structure for providing multimedia services for a client using a terminal A by means of an IMS network 100. In this example, terminal A is a mobile terminal connected to a radio access network 102, even though IMS can be used for fixed terminals as well. An IMS terminal is often generally referred to as “User Equipment (UE)”.
The access network 102 is connected to IMS network 100, which is the “home” IMS network of terminal A and therefore handles multimedia services for terminal A. Basically, multimedia services are handled by the terminal's home IMS network even when roaming in a visited access network. Any multimedia sessions and services for the client of terminal A are controlled by specific session managing nodes in the IMS network 100, including a P-CSCF (Proxy Call
Session Control Function) node 104, an S-CSCF (Serving Call Session Control Function) node 106, and an I-CSCF (Interrogating Call Session Control Function) node 108, according to the conventional IMS architecture of today.
Briefly described, the P-CSCF node 104 acts as the entry point for clients towards the IMS network 100 from access networks, including network 102. A plurality of S-CSCF nodes in the IMS network 100 are assigned to different active terminals for managing their sessions using SIP signalling, and the shown S-CSCF node 106 handles sessions for terminal A in this example. Further, the I-CSCF node 108 acts as a gateway basically receiving SIP messages from other IMS networks 110.
The IMS network 100 also includes one or more application servers 112 for different multimedia services, and a main database node HSS (Home Subscriber Server) 114 where various subscriber and authentication data is stored for clients. The various functions of the shown network elements in IMS network 100 are generally known in the art, but are not necessary to describe here further to understand the context of the present invention.
Each application server 112 supports one or more specific multimedia services such as “Instant Messaging” (IM), “Push-to-talk over Cellular” (PoC) and “Presence”, where SIP signalling is used to control sessions. In particular, presence services basically make data related to an observed client available to other watching clients.
In this description, the term “presence data”, or generally “client data”, is used to represent information on the state or situation of a client and his/her equipment in any predefined respect. Briefly described, presence data of a client is published by storage at an application server generally referred to as a “presence server”, which can be supplied to other clients subscribing to that presence data. The presence data may refer to the following exemplary client states:                A personal status, e.g. available, busy, in a meeting, on holiday, etc.        A terminal status, e.g. switched on/off, engaged, out of coverage, etc.        The geographic location of the client/terminal.        Terminal capabilities, e.g. functionality for SMS, MMS, chat, IM, video, etc.        Terminal selections, e.g. call forwarding, language, etc.        Other client information, e.g. interests, occupations, personal characteristics, moods, personal logos, logo depending on the current mood, etc.        
This type of information is continually stored in presence servers in the IMS network, based on publications of so-called “client events” received from clients or from their access networks, whenever any presence data for a client is introduced, updated, changed or deleted. A client may thus also subscribe for selected presence data of one or more other clients which is also handled by an application server in the IMS network.
In this description, the term “client” will be used to generally represent a user equipment (or communication terminal) and its user. Further, the term “watching client” represents a client that subscribes or requests for presence data (sometimes also referred to as the “Watcher”), and the term “observed client” represents a client that publishes presence data (sometimes also referred to as the “Presentity”) to be available for authorised watching clients.
A SIP message called “SIP PUBLISH” is generally used by observed clients to send their presence data to the presence server for publication. The SIP PUBLISH message can be used basically in four different cases, namely: 1) to initiate new data, 2) to “refresh” data (i.e. confirming that earlier initiated data continues to be valid), 3) to modify data, and 4) to terminate data no longer valid.
Another SIP message called “SIP SUBSCRIBE” is used by watching clients to subscribe for presence data of observed clients, and only authorised clients are entitled to receive such data. The SIP SUBSCRIBE message can be used to obtain presence data either just once or on plural occasions, as determined by a time-out parameter that can be set in that message, often referred to as TTL, “Time To Live”.
If the time-out parameter in a SIP SUBSCRIBE message is set to zero, a notification with requested presence data is obtained just once and the subscription is promptly terminated thereafter. If the time-out parameter is set to a certain time period>0, the watching client will receive notifications until the subscription period expires. Notifications can then be received either automatically using a “push”-type mechanism, e.g. regularly or whenever the data is changed, or upon demand using a “pull”-type mechanism.
FIG. 2 illustrates the present conventional procedure for providing presence data, involving the user equipment A of a watching client and the user equipment B of an observed client belonging to an IMS network comprising a presence server 200 acting for client B. The presence data for client B is maintained in a presence database 202 associated with presence server 200. As shown in the figure, clients A and B are represented by mobile terminals even though the described procedure can be applied for fixed terminals as well.
A first step 2:1a generally illustrates that the observed client B publishes presence data by frequently sending SIP PUBLISH messages to the presence server 200 according to conventional routines, as described above. Certain data for client B can also be sent from client B's access network (not shown), e.g. location data and terminal status data. A next step 2:1b illustrates that database 202 is updated accordingly in response to receiving the SIP PUBLISH messages of step 2:1a. Steps 2:1a and 2:1b continue throughout in the background, according to prevailing routines.
Client A can subscribe to specific presence data by establishing a dialogue with the presence server in which notifications can be received. In a step 2:2, client A thus sends an SIP SUBSCRIBE message as a subscription request for presence data of client B, in which a desired subscription time period is specified for the dialogue. As mentioned above, if the client A wants to receive presence data of client B just once (the pull mechanism), the subscription time=0, but if he/she wants to receive presence data over a longer period (the push mechanism), the subscription time>0. The presence server 200 then retrieves presence data of client B in a step 2:3, and sends it to client A in an initial notification message SIP NOTIFY, as shown in a step 2:4.
As indicated by the dashed arrows, client A may receive such notifications on further occasions during the given subscription time, either at regular intervals or whenever the presence data is changed. The presence server will also reserve certain server resources throughout the subscription period needed to maintain the subscription and provide the desired presence data of client B to client A, including communication and processing resources to receive and forward notifications. In order to prolong or “refresh” the subscription, client A may send further SIP SUBSCRIBE messages just before the subscription time expires, and the presence server will then continue to maintain the subscription and the associated resources.
A watching client may also subscribe to presence data of plural observed clients, which often results in numerous notifications for updated presence data being sent to the watching client. An information delivery server has therefore been proposed called the RLS, “Resource List Server” acting to collect notifications from the observed clients in order to send a single notification for all observed clients to the watching client. This mechanism is sometimes called the “exploder” function. Another solution for reducing the number of notifications by using a combined push/pull mechanism, is disclosed in WO 2005/088949 (Telefonaktiebolaget LM Ericsson AB).
However, if the client user do not want to receive any presence notifications during a limited period, e.g. when not wanting to be disturbed or when being occupied in a session or call or otherwise, the subscription must be terminated. In order to resume the notifications, the subscription must then be re-created, i.e. a completely new subscription must be established. This procedure will now be briefly described with reference to a block diagram in FIG. 3 containing a watching client A, a presence server 300 providing presence data on an observed client B (not shown), as well as a P-CSCF node 302 and an S-CSCF node 304 in an IMS network of the watching client A. It is assumed that a subscription has been created basically in the manner described for FIG. 2 above, and that client A frequently receives notifications with presence data of client B, accordingly.
The user of client A has now decided to withhold the notifications during a period of time, for some reason, and terminates the subscription by means of a suitable input command in the used terminal. In a first step 3:1, client A therefore sends a subscription request message in the current dialogue to the P-CSCF node 302 with the TTL or subscription time set to zero, such as: SIP SUBSCRIBE (expires=0), in order to terminate the ongoing subscription. The P-CSCF node 302 then routes the subscription request message to the presence server 300, in a step 3:2.
The presence server 300 then terminates the subscription and releases all server resources being reserved for the subscription, as indicated by a further step 3:3. Server 300 may also send a final notification to client A at this point, not shown. This means of course that no further presence notifications on client B will be communicated to client A.
When the user of client A later wants to re-create his/her presence subscription, a new dialogue must be established with server 200 and a new subscription request message is sent to the P-CSCF node 302, in a next step 3:4, such as: SIP SUBSCRIBE (expires>0). The P-CSCF node 302 then routes the subscription request message to the S-CSCF node 304 which is given in the request, in a following step 3:5, to re-create the subscription. It should be noted that the S-CSCF node 304 is needed for routing the request to the correct destination, being a request for a completely new subscription. The S-CSCF node 304 accordingly routes the subscription request message of client A to the presence server 300, in a further step 3:6. The presence server 300 will thus establish a new subscription for client A, which involves checking whether client A is authorised to receive presence data of client B as well as reserving various needed server resources for the subscription.
FIG. 4 illustrates a similar procedure when the watching client A subscribes for presence data of plural observed clients B, C, D . . . by means of an RLS node 400. The block diagram of FIG. 4 likewise contains a P-CSCF node 302 and an S-CSCF node 304 in an IMS network of the watching client A. Further, plural presence servers 402 are shown providing presence data on the observed clients B, C, D . . . , respectively. It is assumed that client A frequently receives notifications with presence data of the observed clients from the RLS node 400, by means of an established RLS subscription. RLS node 400 has also established individual back-end subscriptions with the presence servers 402 for each of the observed clients.
Client A decides to withhold the notifications temporarily and terminates the RLS subscription by sending a terminating SIP SUBSCRIBE request (expires=0) within the existing dialogue to the P-CSCF node 302, in a first step 4:1. The P-CSCF routes the request to the RLS node 400 in a step 4:2. The RLS must now terminate all existing back-end subscriptions with presence servers 402, which may be in the range of 10-100, and thus sends terminating SIP SUBSCRIBE requests (expires=0) within the existing dialogues for each presence server subscription, as illustrated in a step 4:3. The RLS node will then naturally receive no further notifications from the presence servers 402.
Sooner or later, client A decides to re-create the subscription and sends an initial SIP SUBSCRIBE request (expires>0) to the P-CSCF 302, in a next step 4:4. The P-CSCF accordingly routes the request to the S-CSCF 304 handling the resource pointed out in the request, in a following step 4:5. The S-CSCF then routes the request to the RLS node 400 to create the RLS subscription for client A, in a next step 4:6.
The RLS node 400 now creates a back-end subscription for each presence server 402 being pointed out by the initial RLS subscription (which may be predefined or ad-hoc), and sends an initial SIP SUBSCRIBE request to the S-CSCF node 304 for the presence server subscriptions, in a further step 4:7. Finally, the S-CSCF node 304 routes a subscription request to each presence server 402 to activate the respective subscriptions, in a step 4:8.
In the above-described conventional solutions of terminating the subscription to withhold notifications, considerable efforts and signalling are required to terminate and re-create presence subscriptions in this manner, as several messages must be communicated between different network nodes and elements, also introducing latency. Re-creating the subscription further requires that a new dialogue is established between the watching client and the presence server, having released the previous dialogue to withhold the notifications.
Further, any client publications and presence updates occurring during the suspension period will never be notified to the watcher. In particular, when an RLS is used in the case of a subscription for plural observed clients, different presence servers of those clients will continuously send notifications to the RLS that will be lost in the current solution. Hence, it would be desirable to avoid or at least reduce the problems above when temporarily withholding notifications with presence or client data to watching clients.